Can you give an example where you want to use this?

# with concerns - able to inherit custom Base class and share connections
module Foo
  class Base < ActiveRecord::Base
  end

  class Version < Base
    include PaperTrail::VersionConcern
  end

  class Document < Base
    has_paper_trail class_name: 'Foo::Version'
  end
end

module Bar
  class Base < ActiveRecord::Base
  end

  class Version < Base
    include PaperTrail::VersionConcern
  end

  class Document < Base
    has_paper_trail class_name: 'Bar::Version'
  end
end

Foo::Base.establish_connection({})
Bar::Base.establish_connection({})

Without concerns, version classes need to have it's own connection because PaperTrail::Version will use ActiveRecord::Base's connection. In addition it's difficult to add common behaviors or override ActiveRecord::Base method on Foo::Version using Foo::Base, because it inherits PaperTrail::Version (and ActiveRecord::Base), not Foo:Base.

# without concerns - need to inherit PaperTrail::Version
module Foo
  class Version < PaperTrail::Version
  end
end
module Bar
  class Version < PaperTrail::Version
  end
end

[Foo::Base, Foo::Version].each { |klass| klass.establish_connection({database: 'foo'}) }
[Bar::Base, Bar::Version].each { |klass| klass.establish_connection({database: 'bar'}) }

So essentially this just makes it easy to use the gem with an application that makes multiple connections to databases. I think this makes sense then since it leaves the original functionality in tact but adds some flexibility. Any chance you could add a test or spec demonstrating the functionality if it's not too much trouble? If nothing else, it makes the use case easy to see for others going forward.

FYI it's idiomatic usage of the AS::Concern module to define your class-level methods in a module called ClassMethods, and not in the included block. Example:

module VersionConcern
  included do
    # macros in here
  end

  module ClassMethods
    def some_class_level_method
    end
  end

  def some_instance_level_method
  end
end

PaperTrail::Version already uses the concern and all existing tests are passed - what kind of tests can we add? any suggestion?

@jherdman I'll make that change - thanks!

@chulkilee - Probably just something similar to your example above, where a custom version class includes the PaperTrail::VersionConcern.

Also, it looks like the portion with the class methods needs to be modified a bit. The object_col_is_json? and object_changes_col_is_json? methods are now class methods. Does that fix all the failing tests?

@fullbridge-batkins fixed and added tests

Yes I saw that, thank you, looks good. Was busy last week but going to merge this soon.

Thanks a lot for this pull, very cool feature. I'm wondering if there is some way to document the usage of this on the README a bit better but perhaps the specs you provided make it obvious. By the way, I refactored the specs a little bit in 975e1bb so it is organized a bit better.

thanks!